In applications coded in programming languages such as C, Pascal, etc., it is common for a section of the program to be executed multiple times, with each execution occurring immediately upon completion of a prior execution. This repetition of workflow may be referred to as iterative programming or “looping.” Looping is an important programming technique that enables an application to repeat a set of instructions or display output over and over until a condition is or a set of conditions are met. Looping may allow a programmer to repeat a set of instructions in an efficient, logical way. Not only may looping be efficient, it may also provide control over how many times a set of instructions in a section of code may be executed.
A program executing a section of code in a loop may continue doing so until some condition or completion event occurs. For example, a loop may execute until an evaluated result of a given expression is false. This type of loop may be referred to as a For loop. Also for example, a loop may execute for each item in a collection. Each item may be pulled from various places in memory based on a memory address. This type of loop may be referred to as a ForEach loop. There are other types of loops well known to those skilled in the art such as, but not limited to, While loops, Jump loops, Until loops, etc.
Instead of using programming languages such as C or Pascal, software applications may be developed using an object model. The object model applications may, in many respects, mimic traditional programming language. An object model may be defined as a collection of objects and relationships. Each of the objects may be associated with one or more properties that govern the execution behavior of the object. An object model may be a collection of objects that may be instantiated. Relationships between instantiated objects may be created to build a cohesive application. Such an object model may have a hierarchy of objects. That is, parent objects may have children objects. The objects may perform functions or operations. Each operation may define a work item to be performed within an object. The operation may perform the work of the application by, for example, copying files, downloading files, cleaning data, performing queries, etc.
A problem exists, however, in applying a programming language looping paradigm to an application built on an object model. Looping constructs in programming languages may freely access items stored throughout memory based on, for example, a memory address. Objects within an object model, on the other hand, may have implicit or explicit boundaries that hinder, for example, iterating over a collection of objects or assigning a variable to a loop.
For example, an object model may use “steps” to control the execution of an operation. To support looping, the object model may require a programmatic approach that stipulates that an object be inserted at some point in a workflow. The object may be capable of modifying the execution status of the execution engine. This object may “trick” the execution engine by indicating that a given section to be executed in a loop was not yet executed even when the section has been executed. This “tricking” may be accomplished by a script object and may be used as many times as the “loop” is needed to run. The script object may go to a parent object, traverse the object model to find the next step, apply a precedence constraint, and then modify the object model by indicating that the operation was not yet executed.
The script task method of employing a looping paradigm in an application based on an object model may be problematic. First, it is complicated. Second, in a user interface, it may not be apparent where a loop ends or starts. Therefore it may be difficult to understand and configure the loop coding. Without well-defined boundaries, there may be no way to represent the loop visually.
It would be useful, therefore, to be able to apply looping constructs to a software application based on an object model such that information or objects located outside a looping construct object may be more easily communicated to a looping construct object. Additionally, it would be useful if the looping construct may be represented visually. Such an approach may enable understanding and configuring of the loop from a user interface.